Private vs. Public
Let's explore the differences between public and private learning.
There are many principles offered in this Coding Career Handbook, but the most important one is: Learn in Public.
Learning in private#
You have been trained your entire life to learn in private. You go to school. You do your homework. You get grades. And you keep what you learned to yourself.
Success is doing this better than everyone else around you, over and over again. It is a constant, lonely, zero-sum race to get the best grades. To get into the best colleges. To get the best jobs. If you’ve had a prior career, the chances are that all your work was confidential. And of COURSE, you don’t share secrets with competitors!
Tech is a fundamentally more open industry. We write blogs about our outages. We get on stage to share our technical achievements. We even give away our code in open source.
You learn in your head#
However, most developers act like tech is the same as every other industry. Most developers bottle up everything they learn in their heads, all the while hoping their careers grow linearly with years of experience at the right companies working on the right projects for the right bosses. Most developers strictly consume technical content without actually creating any themselves.
Hard to find proof of your work#
This is an excellent way to build a career: approximately 99% of developers operate like this. Scott Hanselman calls them Dark Matter Developers. You can infer their presence from GitHub stars and package downloads, but it’s hard to find direct evidence of their work. Their network mainly consists of current or former coworkers.
Job hunting is difficult#
When job hunting, people start from zero every time. They find opportunities only from careers pages or recruiters. To get an interview, they must serialize years of experience down into a one-page resume by guessing employers’ opaque deserialization and filtering algorithms. Then, they must convey enough in 30 to 60-minute interviews to get the job. Even while on the job, picking up new technology is a solitary struggle with docs, books, and tutorials.
Learning in public#
There is another way. You can learn in public instead.
You learn faster#
What do I mean by learning in public? You share what you learn as you learn it. You open source your knowledge.
You build a public record of your interests and progress, and along the way, you attract a community of mentors, peers, and supporters. They will help you learn faster than you ever could on your own. Your network can be vast, consisting of experts in every field, unconstrained by your org chart.
Job hunting is easier#
When job hunting, prospective employers may have followed your work for years, or they can pull it upon demand. Even more likely, they may seek you out themselves, for one of the 80% of jobs that are never published. Vice versa, you take much less cultural risk when you and your next coworkers have known each other’s work for years.
When picking up new technology, you can call on people who’ve used it in production, warts and all, or are even directly building it. They will talk to you because you learn in public.
Win-win situation#
I intentionally haven’t said a single word about “giving back to the dev community.” Learning in public is not altruism. It is not a luxury or a nice-to-have. It is simply the fastest way to learn, establish your network, and build your career. This means it is also sustainable because you are primarily doing it for your own good. It just so happens that, as a result, the community benefits too. Win-win.
You never have to be 100% public. Nobody is. However, try going from 0% to 5%. Or even 10%! See what it does for your career.
Tip: Some vulnerable people have personal safety or other reasons to not learn in public. These concerns are totally valid. Since the majority of the time, we all are still learning in private; it’s worth thinking about how to do that well too.
Principles
Getting Started